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METHOD AND APPARATUS FOR FIG. 5 is a flow chart illustrating a method according to 

REMOTELY CONFIGURING A NETWORK '• one exemplary embodiment of the present invention, of 
DEVICE generating identification information for a network device 

and propagating this information to the central configuration 
FIELD OF THE INVENTION s server. 

The present invention relates generally to the field of FIG - 6 is a flow cnart illustrating a method, according to 

network computing and, more specifically, to the remote one 6xer nplary embodiment of the present invention, of 

configuration of a network device by the provision of generating configuration information for a network device 

configuration information thereto from a remote location. on tne central configuration server and propagating this 

10 configuration information to the network device. 

BACKGROUND OF THE INVENTION FIG. 7 is a flow chart illustrating a method, according to 

Network configuration is a complex, time-consuming and ZJ^l^ em fi bodimem ° f me oresei » invention, of 

expensive task. Specifically, when coupling new network Z fi , 8 C f ° nfi S" ratl0n fi e °° a net ™ lk device ™*& 

devices into a network, or setting uj a new network, 15 ZoZTer mblm ^° 0 reCMVCd fr ° m lhe ^ coaB ^- 

new-coupled network devices must be configured to operate 0 ■ ■ 

within, and communicate over, the network. For example HG- 8 1S a diagrammatic representation of an exchange of 

Internet Protocol (IP) addresses must be allocated to net- messa g es between a network device, a DHCP server and a 

work devices, routing protocols specified, and subnets central configuration server, according to one exemplary 

defined for such devices. As networks continue to become 20 embodiment of the present invention, 

more complex, the simplification of the configuration pro- FIG - ' is a block diagram showing an exemplary manner 

cess is becoming increasingly attractive and necessary. m which a configuration domain may be identified for a 

network device that requires location-specific configuration 

SUMMARY OF THE INVENTION parameters. 

According to a first aspect of the invention there is 25 FIG - 10 is a block diagram illustrating an exemplary 

provided a method of remotely configuring a network manner 10 w , hich a ^figuration domain may be identified 

device. Configuration information for the network device is f ° r a netWOrk device lhat does not re ^ uire l°cation-specific 

generated at a location remote therefrom, this configuration configuration parameters. 

information including a device configuration parameter. In ^IG. 11 is a block diagram illustrating a modified Domain 

response to the receipt of identification information from the 30 Configuration File (DCF) constructed according to the 

network device at the remote location, the configuration teachings of the present invention. 

information is propagated to the network device. FIG. 12 is a diagrammatic representation of a machine 

. According to a second aspect of the invention, there is within which instructions for executing any one of the 

provided an apparatus for remotely configuring a network 3S methodologies of the present invention may be executed, 
device. The apparatus includes a configuration server to 

generate configuration information for the network device. 1 AILED DESCRIPTION 
The configuration server is located remote from a network A method and apparatus for remotely configuring a net- 
device, and the configuration information includes a device work device are described. In the following description, for 
configuration parameter. The apparatus also includes a com- 40 purposes of explanation, numerous specific details are set 
munications interface to propagate the configuration infor- forth in order to provide a thorough understanding of the 
mation from the configuration server to the network device present invention. It will be evident, however, to one skilled 
in response to receipt of identification information concern- in the art that the present invention may be practiced without 
ing the network device at the configuration server. these specific details. 

Other features of the present invention will be apparent 45 The parameters controlling the behavior of a networking 

from the accompanying drawings and from the detailed device are typically stored within a configuration file (or 

description which follows. config file). The configuration file may be created by the 

„„„ „ networking device itself or by some other configuration- 

BRIEF DESCRIPTION OF THE DRAWINGS capable device and then installed on the network device. 

The present invention is illustrated by way of example 50 Within a neIworkin g device, the configuration file may be 

and not limitation in the figures of the accompanying Slored w,lhm a memory resource, such as static or flash 

drawings, in which like references indicate similar elements read-only memory (ROM). Alternatively, the configuration 

and in which: °' e mav ° e store d on some other file server coupled to the 

pir 1 ,v , j;,„, ,• c networking device. When a networking device boots, the 

HU. 1 is a diagrammatic representation of message ,k c .• *i .i- j. ... 

exchanges between a client and server according to the 55 IZ^T V f Ration file are utilized to mrtiate 

Dynamic Host Configuration Protocol (DHCP). 8 T^TiT • ° "^"f * a \? ay , b ? ? 

„„ - . ,. . : , / 'he type, location and intended functionality of the device. It 

FIG 2 is a diagrammatic representation of an exemplary will be appreciated that while type information (for example 

network within the present invention may be implemented. whc ther the device is a router, switch or hub) for a network- 

FIG. 3 is a block diagram illustrating a central manage- 60 ing device will be known at manufacture, the final location 

ment system, and the interaction between the central man- and intended functionality for the networking device will 

agement system and a configuration domain border router only be known upon installation. Accordingly, many of the 

and subdomain routers, according to one embodiment of the parameters within the configuration file can only be ascer- 

present invention. tained upon installation. 

FIG. 4 is a flow chart illustrating a method, according to 65 As the parameter values to be incorporated within 

one exemplary embodiment of the present invention, of configuration file are typically not known at time of 

remotely configuring a network device. manufacture, a default configuration file may be shipped 
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with new network devices that may be used to boot the 
network device for the first time. This default configuration 
file is intended to bring the network device to an initial state 
in which more specific configuration may be entered, and is 
not intended for use within a fully installed networking 
device. 

The configuration of a network device can be viewed as 
constituting two processes, namely (1) the creation of the 
configuration file and (2) the delivery of this configuration 
file to the networking device. Assuming a network device, 
such as a router, is residing in a default initial state, there are 
a number of ways in which the final configuration file may 
be constructed for a network device. First, if the installation 
environment is known at manufacture and shipping, a net- 
work device may be preconfigured with all relevant con- 
figuration parameters, including network addresses, protocol 
parameters, etc. When the device boots, all necessary con- 
figuration information is retrieved, for example, from a local 
flash memory, and the systems administrator will in this case 
not be required to perform any configuration tasks. Second, 
a system administrator may manually configure all neces- 
sary configuration parameters on-site via, for example, a 
console port connection. Third, a system administrator may 
utilize remote manual configuration to install a configuration 
file on, for example, a flash memory of a network device 
such as a router. In this case, the configuration file is created 
remotely from the installation site; and then transferred to 
the network device. The present invention teaches such a 
system and methodology. 

Regarding delivery of a configuration file to a networking 
device, a number of methods may be utilized to deliver a 
configuration file, constructed utilizing the teachings of the 
present invention, to a networking device. First, where a 
network device is preconfigured, obviously no delivery 
mechanism is required. Second, where a networking device 
contains a removable storage media, such as for example a 
PCMCIA disk, the storage media may be physically moved 
from a configuration construction location and inserted into 
a network device, whereafter the configuration file may be 
copied from the removable storage media into the network 
device memory resource. No network connectivity is 
required for this method. Third, a systems administrator may 
initiate a manual file transfer program (for example, FTP or 
TFTP) between the networking device and a file server 
storing a configuration file. Some level of network connec- 
tivity to the network device is required over which such a file 
transfer can be conducted. Finally, an automatic file transfer 
may be utilized, which is similar to the above mentioned 
manual file transfer, except that the network device may in 
this case initiate the file transfer procedure automatically 
after determining the location of an appropriate configura- 
tion file via a configuration protocol. To such configuration 
protocols included the Bootstrap Protocol (BOOTP) and the 
Dynamic Host Configuration Protocol (DHCP). 

In one embodiment, the present invention teaches utiliz- 
ing DHCP or BOOTP to implement a method of the 
remotely configuring a network device. DHCP is fully 
described in the Request For Comments (RFC) 2131, and 
BOOTP is fully described in RFC 951. DHCP utilizes the 
same frame formats as BOOTP and provides additional 
capabilities. Accordingly DHCP may be considered as an 
extension of BOOTP. A brief description of DHCP will now 
be provided with reference to FIG. 1. DHCP is primarily a 
protocol for assigning dynamic Internet Protocol (IP) 
address to devices on a network. Accordingly, DHCP per- 
mits the automatic configuration of IP parameters on net- 
work devices. However these configuration parameters are 
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interface specific, and do not include global or non-interface 
specific configuration parameters, such as for example 
router parameters. 

When a DHCP client 10 boots, it transmits a DHCP 
5 discover message 12 on each local subnet to which the 
DHCP client 10 is connected (that is from all interfaces of 
the device hosting the DHCP client) to DHCP servers 14 
coupled to such networks. Each subnet DHCP server 14 may 
then respond with a DHCP offer message 16 that includes an 
10 available network IP address. The DHCP client 10 receives 
one or more DHCP offer messages 16, and then selects one 
server from which to request configuration parameters, 
based on configuration parameters within the DHCP offer 
messages 16. The DHCP client 10 then broadcasts a DHCP 
1S request message 18 to each of the DHCP servers 14, each of 
the request messages 18 including a server identification to 
indicate the server selected. The DHCP server 14 selected 
then responds to the DHCP request message 18 with a 
DHCP acknowledge message 20 containing the configura- 
20 tion parameters requested by the DHCP client 10. It should 
be noted that the configuration parameters provided to the 
DHCP client 10 from the selected DHCP server 14 are 
configuration parameters for the host only (i.e., PCs or work 
stations that require only network address, mask of default 
25 gateway address information for a particular interface on the 
host). Such hosts typically run applications that generate 
network traffic which is propagated on a network via a 
default gateway. The configuration information supplied by 
the DHCP server 14 is usually LAN specific, and manages 
30 configuration parameters for the relevant LAN. 

As stated above, DHCP permits the automatic configura- 
tion of IP parameters on an IP host, these configuration 
parameters being interface specific, and non-global. In one 
embodiment of the present invention, additional information 
35 is included within DHCP messages, by way of proprietary 
extensions, so as to allow for the exchange of information 
between a client 10 and server 14 beyond the definition in 
the DHCP specification. In a further embodiment, the con- 
figuration parameters returned to the client 10 from the 
40 server 14 may include the location of a configuration file. 
Upon receipt of information indicating this location, a client 
10 may initiate an automatic file transfer operation to 
retrieve the configuration file. 

Finally, the present invention teaches that the Simple 
45 Network Management Protocol (SNMP), as the detailed in 
RFC 1157 may be utilized to transfer configuration infor- 
mation from a remote location, such as a server, to a network 
device. SNMP is specifically suited to situations where only 
a few parameters require configuration, as each request/ 
50 response exchange modifies only a single parameter. 

FIG. 2 is a diagrammatic representation of an exemplary 
network 22 within which the present invention may be 
implemented. The network 22 is shown to include a central 
management system 24 that includes, inter alia, a central 
55 configuration server 26 coupled to a topology database 28. 
The topology database 28 is utilized by the central manage- 
ment system 24 to store and retrieve information concerning 
the physical and logical topology of the network 22. 
Specifically, the physical topology information includes 
60 descriptions of physical network devices, and their physical 
connectivity. For example, information concerning a device 
type (for example, router or switch), level 2 (L2) addresses 
and orts may be included within the physical topology 
information. The logical topology information includes level 
65 3 (L3) interface information and includes network address, 
subnet and routing protocol information. The physical topol- 
ogy information can be constructed utilizing a number of 
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different mechanisms, such as a physical topology discovery 
protocol that collects information from physical topology 
MIBs on network devices. Logical topology information 
may be constructed through a relationship between physical 
topology MIB information and interface MIB information. 
The topology database 28 gathers this information, and 
utilizes it to construct physical and/or logical representations 
of the network 22. The topology database 28 may also be 
manually configured thus allowing new networks to be 
designed and classified. 

The central configuration server 26 is shown to the 
resident on a dedicated host. It will however be appreciated 
that the central configuration server 26 could be accommo- 
dated on a shared host that also accommodates other servers 
comprising the central management system 24. 

The network 22 is further shown to include four exem- 
plary configuration domains 30, 32, 34 and 36. Specifically, 
utilizing the physical and logical topology information 
included within the topology database 28, the network 22 
may be divided into a number of configuration domains, the 
boundaries of each configuration domain being dependent 
upon the size of the network 22, as well as the physical and 
logical topology. For example, a configuration domain may 
consist of a group of network devices within a specific OSPF 
area, as is the case with the network 22 illustrated in FIG. 2. 
According to one embodiment of the present invention, a 
configuration domain may comprise a portion of a network 
in which network entities are capable of "auto configura- 
tion" when appropriate topological information is supplied 
from the topology database 28. Each configuration domain 
may furthermore be divided into one or more subdomains. 
Depending on the way in which subdomains are defined, and 
the location and desired function of devices within the 
subdomains, some network devices within a subdomain 
may, according to one embodiment of the present invention, 
be able to determine appropriate configuration parameters 
for their interfaces by learning about the configuration 
information of neighboring devices. 

Each of the domains 30-36 comprises an OSPF area and 
includes a number of routers 40, the routers within the 
domain 30 comprising a backbone portion of the network 
22. The routers within the domains 32, 34 and 36 are 
designated as being Subdomain Routers (SDRs) as each has 
interfaces only in one configuration domain. Specifically 
each Subdomain Router is exclusive to one configuration 
domain, or part of one or more subdomains within a con- 
figuration domain. The routers 40 within the domain 30, on 
the other hand, may conveniently be identified as Configu- 
ration Domain Border Routers (CDBRs), as each has inter- 
faces in different configuration domains. For example, router 
40B one interface in the domain 34, and another interface in 
the domain 36. Configuration of CDBRs requires informa- 
tion concerning network topology, and how configuration 
domains within the network have been defined. Typically, 
configuration domains and subdomains will be defined 
based on logical network topology. For example, configu- 
ration domains can be made up of one or more OSPF areas, 
and each subdomain within a configuration domain can be 
one OSPF area. 

FIG. 3 is a block diagram showing further details regard- 
ing the central management system 24, and the interaction 
between the system 24 and a configuration domain border 
router 60 and subdomains routers 62 and 64. Referring 
firstly to the central management system 24, access to the 
topology database 28 is provided through a database access 
module 54, that is available to the central configuration 
server 26, a file server 50 and a DHCP server 52. A graphical 



user interface (GUI) 56 facilitates user interaction with the 
central management system 24. Configuration files 58 are 
shown to be stored on the central configuration server 26, 
and are delivered therefrom to routers according to the 
5 methodologies discussed below. The DHCP server 52 is 
responsive to DHCP clients (not shown) hosted on network 
devices, in the manner described above. Upon boot of a 
network device or when triggered by a system administrator, 
a DHCP client transmits a DHCP discover message 112 on 
io each of its interfaces. The DHCP server 52, in response to 
the receipt of discover messages 112, may function to direct 
a network device to a configuration file based on the 
identifier supplied within a discover message. While the file 
server 50, the DHCP server 52 and the central configuration 
15 server 26 are shown to comprise discrete entities within the 
system 24, it will be appreciated that these servers may be 
tightly integrated into a single server application. The con- 
figuration domain border router 60 is shown to store a 
pre-configuration file 66 (which may conveniently be termed 
20 a "cookie"), the use of which will be described in further 
detailed below. The components illustrated in FIG. 3 pro- 
vided the structural basis for the functional description that 
follows below. 

FIG. 4 is a flow chart illustrating the broad steps of a 
25 method 70, according to one exemplary embodiment of the 
present invention, of remotely configuring a network device, 
such as for example a router or a switch. The method 70 
commences at step 72, and at step 74, a network device 
identifies or determines identification information concem- 
30 ing itself, and propagates this identification information to 
the central configuration server 26. At step 76, the central 
configuration server 26 constructs configuration 
information, for example in the form of a Domain Configu- 
ration File (DCF), which may comprise a file containing 
35 configuration parameter information for a specific configu- 
ration domain. The configuration information is then propa- 
gated from the central configuration server 26 to the target 
network device associated with the identification informa- 
tion. At step 78, the target network device then constructs a 
configuration file, utilizing the configuration information 
received from the server 26, whereafter the method 70 
terminates at step 80. 

FIG. 5 is a flow chart illustrating a method 74 of imple- 
menting the step 74, according to one exemplary 
embodiment, of the method 70 shown in FIG. 4. 
Specifically, the method 74 is performed by a network 
device, such as either one of the subdomains routers 62 or 
64, or the configuration domain border router 60, shown in 
FIG. 3. Following commencement at step 82, the network 
50 device boots and accesses a default configuration file at step 
804. The default configuration file brings the network device 
into a default initial state at step 86, whereafter a determi- 
nation is made at decision box 88 as to whether the network 
device has been preconfigured with a pre-configuration file 
55 66, such as for example a "cookie". Specifically, certain 
network devices may require location-specific, or function- 
specific, configuration parameters. Such devices are most 
typically configuration domain border routers 60 (for 
example, core routers) which need to know whether they 
60 belong to a backbone network and which area, or stub, 
networks they are attached to. Such information is not 
readily obtainable through neighbor discovery, and accord- 
ingly such network devices may be unable to supply the 
central configuration server 26 with enough information to 
65 be recognized as a fitting into a configuration domain (as 
will be described below), and accordingly some pre- 
configured information must be passed to the central con- 
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figuration server 26 to obtam appropriate configuration abilities and model information of the network device The 

parameters. The pre-configuration file 66 may uniquely central configuration server 26 then issues a response mes- 

nZh/r nf n T°f h , m ? rmS ° f ^ e u^ 6 ° f sa 8 e U2 to the network device 61, requesting further 

sTctfcd v uZ'elvvf, ° D , map 1 hh DetWOrk ?• to which the network device 61 responds with 

4 P re - confi gV'? tlon l fi' e 66 > "»s pre- determines Aether further information is needed. If the 

configurafor. fie 66 1S propagated from the network device configuration information is determined by the configuration 

to the central configuration server 26 at step 90. in crrvi-r •><; t„ i,.. i . a ; n .u ■ "6""""" 

Alternatively, should the network device not have a pre- ™ll 116 t ^ P 1 h W ^ * ^P 0 ™ 

configuration file 66 assigned thereto, the network dev £e mlncludfrl ? fi ? f th * res P°" ssa S e 

m ... ftvf>/*i*it* « nAinkknr J' j 110 including a file name for a file, containing configuration 

'^Lhhnr H g « f P ? CedUI ! at u St6P «f°nnation, that the network devk* may retrieve milizing 

wnrWtpv discovery may be a procedure whereby a net- a flle ^stet protocol, such as TP. This method is advan 

? ^ ^ y de ' erml r fT 311011 te i ated 10 15 ,a S e <™ ™ «hat the central configuration server 26 may issue 

nei^hnr ^"f 'I™ ^ °" b * lea T g , * as many response messages to the network device as are 

n^S? rt ? g 7 t H eVKeS ' Ff T, 3 leVe ' 3 , ( " re 1 uired to ^ M ^Sired configuration information, 

perspective, a network device may determine its logical , . f( , , ... . . , 

connectivity by compiling a list of directly connected sub- • , bo ™ ° f ( me above , embodiments physical ^configuration 

nets. A network device may also determine from neighbor- 20 lnf ° rmatlon to ^included w.th.n the identificanon infor- 

ing devices details concerning OSPF areas, subnets masks maU ° n P ro P a g ated fr ° m the netw °* devlce l ° ^ central 

and time-out values. Certain parameters may however not be confi S" ratlon *™ 26 may include: 

discoverable in this manner, such as the first portion of IP ^ model of the network device; 

addresses and filters. From a level 2 (L2) perspective, a 2 - A code level for me network device; 

' network device may compile a list of directly connected 25 ^' A ^ st °^ optional features installed on the network 

network devices. Many level 2 (L2) devices may require device, such as for example extra memory or additional 

minimal configuration as the spanning tree algorithm may processors; 

dynamically adjust network connectivity. However, with the 4. The number of interfaces available on the network 

enetration of proprietary VLAN and Quality of Service device; and 

(QoS) implementations, the configuration of level 2 (L2) 30 5. Per port information, such as an interface identifier, a 

devices is becoming increasingly complex. Further, a net- port hardware address, and interface type and speed 

work device may use either passive or active network information. 

discovery procedures. For example, when performing a Logical configuration information to be included within 

passive discovery procedure, a network device may listen on the identification information propagated from the network 

its ports for OSPF, DHCP, or router discovery messages, and 35 device to the central configuration server 26 may include the 

then use these messages to determine the subnets on each following per port information: 

port. Alternatively, the network device may actively partici- 1. An interface identifier; 

pate in the router discovery process to learn of neighboring 2. IP subnets learned on the interface or, alternatively IP 

network devices. In a further embodiment of the present addresses for neighbor routers- and 

invention, the central management system 24 may include a 40 3. Connected networks of other protocols supported by 

" apple ' C0Uldbe d ° wnl ° ad * d the code level such as, for example IPX neLorks or 

to a network device to perform neighbor discovery. AppleTalk zones 

Having collected information regarding the network envi- FIG. 6 is a flow chart illustrating a method 76, according 

ronment at step 92, the network device then propagates this to one exemplary embodiment of the present invention of 

information to the central configuration server 26 at step 94. 45 implementing the broad step 76 of the method 70 illustrated 

The method 74 then terminates at step 96. Returning to the in FIG. 4; that is the step of constructing configuration 

steps 90 and 94, the identification information, either in the information for a network device remotely of a network 

form of information discovered utilizing a neighbor discov- device and at the central configuration server 26 The 

ery procedure or a pre-configuration file 66, may be com- mc thod 76 commences at 120, and then proceeds to step 

mumcated from the network device to the central configu- 50 122, wherein the identification information, propagated 

ration server 26 in a number of ways. Specifically, the f rom me network device at either step 90 or step 94 as 

exchange procedure could entail a single request/response illustrated in FIG. 5, is received at the central configuration 

exchange wherein neighbor information and/or pre- server 26. At step 124, a configuration domain, subdomain 

configuration information is propagated from either one of or class to which the relevant network device belongs is 

the subdomains routers 62 and 64, or the border router 60, ss identified. The process of identifying the relevant configu- 

as dlustrated at 100 in FIG. 3. The central configuration ration domain is dependent upon the information supplied 

server 26 then propagates configuration information 102 to from the network device, and determines the extent to which 

the network device in response to the information 100. the generation of configuration information at step 126 may 

Alternatively, an exchange operation could be incorpo- be automated. For example, the generation of configuration 
rated within, or on top of, the DHCP protocol to provide a 60 information for a network device that is functioning as a leaf 
robust exchange as illustrated in FIG. 8. Specifically, in this router may be automated to a greater extent than the gen- 
embodiment of the invention, a networking device firstly eration of configuration information for a network device 
executes a DHCP procedure to obtain an IP address for itself, which is functioning as a core router. Specifically, as 
and to obtain an IP address for the central configuration described above, certain network devices, such as core 
server 26, in the manner described above. Following this 65 routers functioning as configuration domain border routers 
exchange, the network device may send a request message 60, may require location-specific, or function-specific con- 
110 to the central configuration server 26 indicating the figuration parameters, hat may be preconfigured on the 
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network device in the form of a preconflguration file 66 or 
"cookie". Other devices, on the other hand, within a con- 
figuration domain or subdomain may not require such 
location-specific configuration information. For such 
devices, it may be possible to generate generic configuration 
class parameters. Subdomain routers, for example operating 
as the routers, may fall into this category. Specifically, 
wherein a defined configuration domain is contained entirely 
within an OSPF area boundary, and a subdomain router is 
entirely within such an OSPF area, the router may be able to 
obtain information concerning the OSPF area. By propagat- 
ing such information to the central configuration server 26, 
an appropriate configuration domain for the network device 
may be identified using this information. 

FIG. 9 is a block diagram showing an exemplary manner 
in which a configuration domain may be identified for a 
network device that requires location-specific, or function- 
specific, configuration parameters, as required at step 124. 
Specifically, identification information 150 is shown to be 
received from the network device at the central configura- 
tion server 26. The identification information 150 is further 
shown to include a "cookie", for example in the form of a 
unique device-level MAC address 152. The central configu- 
ration server 26 may maintain a mapping of MAC addresses 
to configuration information in a table 154. The configura- 
tion information corresponding to the MAC address 152 is 
included within configuration information in the form of a 
domain Configuration File (DCF) 156. The DCF 156 may 
also include an IP address 158 generated by the DHCP 
server 52. In this case, the configuration domain to which the 
network device belongs may be considered location-specific 
to included only the relevant network device (i.e., a single- 
device domain). 

FIG. 10 is a block diagram showing an exemplary manner 
in which a configuration domain may be identified for a 
network device that does not require location-specific, or 
function-specific, configuration parameters. Specifically, 
identification information 160 is shown to be received from 
the network device at the central configuration server 26, 
this identification information 160 including information 
162 discovered utilizing a neighbor discovery procedure. 
For example, the identification information 160 may include 
information concerning what subnets local interfaces of the 
network device are attached to, subnets masks, and routing 
protocols. At the central configuration server 26, the iden- 
tification information 160 is utilized to identify a configu- 
ration domain (or configuration class) of which the network 
device forms a part. Specifically, the central configuration 
server 26 may maintain a mapping of identification infor- 
mation to generic configuration information 155 pertaining 
to, and appropriate for, a specific domain. It will be appre- 
ciated that, as generic configuration information 155 is 
maintained on a domain by domain basis and not a device by 
device basis, the size of information table 164 will be much 
reduced relative to the size of a similar table which stores 
configuration information on a device by device basis. As 
shown in FIG. 10, subdomain information tables 166, 168 
and 170 may also be defined for each subdomain which 
exists within the configuration domain associated with the 
table 164. The subdomain tables 166-170 may maintain a 
mapping of subdomain-specific configuration information 
167 to identification information, as may be genetically 
applied to the appropriate subdomain. Further, the subdo- 
main information tables 166-170 are shown to inherit con- 
figuration information from the domain information table 
164, and accordingly need only store configuration infor- 
mation specific to a subdomain. The generic configuration 
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information retrieved from the tables 164-170 is then 
included within configuration information, in the form of a 
DCF 156, propagated from the central configuration server 
26 to the network device. The DCF 156 may again include 
an IP address 158 generated by the DHCP server 52. 

The concept of configuration domains, and subdomains, 
is useful within the central configuration server 26 for 
limiting the amount of configuration information that must 
be maintained, as described above. Specifically, devices not 
requiring location-specific or function-specific configuration 
parameters may share common configuration attributes that 
can be effectively maintained at the central configuration 
server 26 as one set of default parameters (that is, the generic 
configuration information stored within the tables 164-170) 
appropriate for a set of network devices within a configu- 
ration domain. When a configuring network device requests 
configuration information from the server 26, the network 
device supplies identification information, either learned or 
pre-configured, to the server 26. Based on this identification 
information, the server 26 may identify the network device 
as belonging to one or more configuration domains or 
classes. The server 26 then supplements the default or 
common configuration parameters with any specific param- 
eters for the device, such as an IP address from the DHCP 
server 52. 

Returning to the flow chart shown in FIG. 6, configuration 
information for the configuring network device is generated 
at step 126 according to the configuration domain. As 
explained above with reference to FIGS. 9 and 10, this step 
of generating the configuration information may be fully 
manual, fully automatic, or partially manual and partially 
automatic. Specifically, where a network device is recog- 
nized as being located within a specific configuration 
domain, default configuration parameters for that configu- 
ration domain may be identified. Where additional configu- 
ration parameters, outside the ambit of the default configu- 
ration parameters, are required, these may be obtained by 
manually prompting a system administrator to input appro- 
priate values. Alternatively, stored configuration 
information, previously inputted by the system 
administrator, may be accessed to supplement the default 
configuration parameters. At one end of the spectrum, the 
system administrator may be required to manually input all 
configuration parameters to construct the configuration 
information. At the other end of the spectrum, the config- 
uring network device may be fully configurable using 
default configuration parameters, in which case configura- 
tion will be fully automated without system administrator 
input for the configuring device. It also significant that the 
input of non-default configuration parameters and the iden- 
tification of default configuration parameters is performed at 
the central configuration server 26, which is located 
remotely of the configuring network device. 

At step 128, the central configuration server 26 then 
propagates configuration information, in the form of a DCF 
156, to the configuring network device. FIG. 11 is a block 
diagram providing an illustration of an exemplary Domain 
Configuration File (DCF) 156. The DCF 156 is shown to be 
made up of a number of objects that contained configuration 
parameters for the configuring network device. Such objects 
may include an OSPF protocol object 180 that contains the 
necessary parameters for configuring OSPF interfaces of the 
configuring network device such as, for example, area 
identifiers and timer values. The DCF 156 may also include 
a RIP protocol object 182, which would be common to all 
DCF's 156 issued to configuring network devices within all 
configuration domains. Other objects included within the 
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DCF 156 may include differentiated services and QoS 
parameters. For example, objects may specify queuing dis- 
ciplines supported by the network device, such as for 
example round robin (RR), weighted round robin (WRR), 
weighted fair queuing (WFQ), priority queuing (PQ). A 
further object may include information regarding scheduling 
algorithms, such as for example random early detection 
(RED), weighted random early detection (WRED) and tail 
drop (TD). As with routing protocol information, the above 
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purposes of this application, the terms switching system 
products shall be taken to mean private branch exchanges 
(PBXs), central office switching systems that interconnect 
subscribers, toll/tandem switching systems for interconnect- 
ing trunks between switching centers, and broadband core 
switches found at the center of a service provider's network 
that may be fed by broadband edge switches or access 
muxes, and associated signaling, and support systems and 
services. The term transmission system products shall be 
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step 130. nG 7 is a flow chart illustrating a method 78 of Thus, a method and apparatus for remotely configuring a 

executing the broad step 78 of the method 70 shown in FIG. network device have been described. Although ttaJS 

4 that is the step of constructing a configuration file (config invention has been described with reference to specific 

file) on a configuring network device. The method 78 exemplary embodiments, it will be evident that various 

commences at step 190, and proceeds to step 192 where the 20 modifications and changes may be made to these emboT 
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configuring network device receives configuration 
information, for example in the form of a DCF 156. At step 
194, the configuring device automatically constructs a con- 
figuration file utilizing the configuration information con- 
tained in the DCF 156. At step 196, the network device then 25 
reboots using the newly generated configuration file, and 
then enters a fully operational and configured state at step 
198. The method 78 then terminates at step 200. 

FIG. 12 is a diagrammatic representation of a machine 
220, which may comprise a server, router, switch or any 30 
other computer system or network device, within which 
instructions for. executing the methodologies described 
above may be executed. The machine 220 is described 
below as including a number of components. It will however 
be appreciated that, depending on the functionality of the 35 
machine 220, a number of these components may not be 
present. In addition, the machine 220 may include further 
components that are not described and illustrated. The 
machine 220 is shown to include a processor 222, a main 
memory 224 and a static memory 226, which communicate 40 
via a bus 228. The machine 220 may also optionally include 
a video display 230 (for example, a liquid crystal display 
(LCD) or a cathode ray tube (CRT)). The machine 220 
further includes an alphanumeric input device 232 (for 
example, a keyboard), a cursor control device 234 (for 45 
example, a mouse), a disk drive unit 236, a signal generation 
device 238 (for example, a speaker) and a network interface 
device 240. The disk drive unit 236 accommodates a 
machine-readable medium 24 on which a sequence of 
instructions, embodying any one of the methodologies 
described above, may be stored. The instructions are also 
shown to reside, completely or at least partially, within the 
main memory 224, the static memory 226, or the processor 
222. The instructions may furthermore be transmitted or 
received via the network interface device 240. Accordingly, 
for the purposes of the specification, the term "machine- 
readable medium" shall be taken to include any medium that 
is capable of storing or encoding a sequence of instructions 
for execution by a machine, and that cause the machine to 
perform the methodologies of the present invention. 
Specifically, the term "machine-readable medium" shall be 
taken to include, but not be limited to, solid-state memories, 
optical and magnetic disks, and carrier-wave signals. 

In alternative embodiments, the present invention may be 
applicable to implementations of the invention in integrated 
circuits or chip sets, wireless implementations, switching 
system products and transmission system products. For the 



ments without departing from the broader spirit and scope of 
the invention. Accordingly, the specification and drawings 
are to be regarded in an illustrative rather than a restrictive 
sense. 
What is claimed is: 

1. A method of remotely configuring a network device, the 
method including: 

discovering identification information indicating a loca- 
tion of configuration information by utilizing a neigh- 
bor discovery process executed by the network device; 
in response to receipt of the identification information 
from the network device at a location remote from the 
network device, propagating the configuration infor- 
mation to the network device; 
automatically determining the location of the configura- 
tion information; 

the network device initiating a file transfer procedure via 
a host configuration protocol to transfer the configura- 
tion information to the network device; 
the network device utilizing the configuration information 
to generate a configuration file, wherein the configu- 
ration information for the network device is generated 
at the remote location using a topology database, and 
identifying a configuration domain to which the net- 
work device is assigned, the configuration information 
including a device configuration parameter, in accor- 
dance with the configuration domain, and a subnet 
identifier for each interface of the network device. 

2. The method of claim 1, wherein the network device is 
a router and the device configuration parameter is a global 
router parameter. 

3. The method of claim 1, wherein the device configura- 
tion parameter is a non-interface specific parameter. 

4. The method of claim 1, wherein generating configura- 
tion information comprises at least partially generating the 
configuration information in a manual manner. 

5. The method of claim 1, wherein generating configura- 
tion information comprises at least partially generating the 

60 configuration information in an automatic manner. 

6. The method of claim 5 further comprising dynamically 
assigning a network address to the network device, and 
including the network address within the configuration 
information. 

7. The method of claim 1 further comprising including 
routing protocol information within the configuration infor- 
mation. 
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8. The method of claim 1 further comprising including an 
IP address for each interface of the network device within 
the configuration information. 

9. The method of claim 1, wherein the identification 
information includes a pre-configured configuration param- 5 
eter value. 

10. The method of claim 1, wherein the identification 
information includes a device-level MAC address. 

11. The method of claim 1, wherein the information 
discovered includes any one or more of routing protocol, 10 
local interface subnet connection or subnet mask informa- 
tion. 

12. The method of claim 1, wherein the configuration 
information includes a plurality of configuration objects. 

13. The method of claim 1, wherein the remote location is 
comprises a configuration server. 

14. Apparatus for remotely configuring a network device, 
the apparatus including: 

a central management system including a topology data- 
base and a central configuration server, which identifies ^ 
a configuration domaio to which the network device is 
assigned, to generate configuration information for the 
network device, the configuration server being remote 
from the network device, the configuration information 
including a device configuration parameter, in accor- 25 
dance with the configuration domain, and subnet infor- 
mation for each interface of the network device, and the 
configuration server upon receiving identification 
information, transfers to the network device the con- 
figuration information based on the identifier supplied 30 
within the identification information; and 

a communications interface to propagate the configura- 
tion information from the configuration server to the 
network device in response to receipt of the identifi- 
cation information concerning the network device at 35 
the configuration server, wherein the identification 
information includes information discovered by a 
neighbor discovery procedure executed by the network 
device. 

15. The apparatus of claim 14, wherein the network 40 
device is a router and the device configuration parameter is 

a global router parameter. 

16. The apparatus of claim 14, wherein the device con- 
figuration parameter is a non-interface specific parameter. 

17. The apparatus of claim 16, wherein the configuration 45 
server at least partially generates the configuration informa- 
tion responsive to the identification information in an auto- 
matic manner. 

18. The apparatus of claim 17, wherein the configuration 
server includes a dynamically assigned network address 
within the configuration information. 
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19. The apparatus of claim 18 further including a server 
for automatically assigning the network address to the 
network device. 

20. The apparatus of claim 14, wherein the configuration 
server automatically includes routing protocol information 
within the configuration information. 

21. The apparatus of claim 14, wherein the configuration 
server automatically includes IP address information for 
each interface of the network device within the configuration 
information. 

22. The apparatus of claim 14, wherein the identification 
information includes a pre-configured configuration param- 
eter value. 

23. The apparatus of claim 14, wherein the identification 
information includes a device-level MAC address. 

24. The apparatus of claim 14, wherein the information 
discovered includes any one or more of routing protocol, 
local interface subnet connection or subnet mask informa- 
tion. 

25. The apparatus of claim 14, wherein the apparatus 
comprises a switching system product. 

26. The apparatus of claim 14 further comprises a trans- 
mission system product. 

27. A machine-readable medium storing a sequence of 
instructions that, when executed by a machine, cause the 
machine to perform the steps of: 

discovering identification information indicating a loca- 
tion of configuration information by utilizing a neigh- 
bor discovery process executed by a network device; 

in response to receipt of the identification information 
from the network device at a location remote from the 
network device, propagating the configuration infor- 
mation to the network device; 

automatically determining the location of the configura- 
tion information; 

the network device initiating a file transfer procedure via 
a host configuration protocol to transfer the configura- 
tion information to the network device; 

the network device utilizing the configuration information 
to generate a configuration file, wherein the configu- 
ration information for the network device is generated 
at the remote location using a topology database, and 
identifying a configuration domain to which the net- 
work device is assigned, the configuration information 
including a device configuration parameter, in accor- 
dance with the configuration domain, and a subnet 
identifier for each interface of the network device. 
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